[Chapter 11] 11.6 Less Common Tasks
Author: Cricket Liu & Paul Albitz
Date: 1999-01-06T18:37:38Z

#

| Chapter 11 nslookup |

## 11.6 Less Common Tasks

These are tricks you'll probably have to use less often, but which are very handy to have in your repertoire. Most of these will be helpful when you're trying to troubleshoot a DNS or BIND problem; they'll enable you to grub around in the packets the resolver sees, and mimic a BIND name server querying another name server or transferring zone data.

### 11.6.1 Seeing the Query and Response Packets

If you need to, you can direct `nslookup` to show you the queries it sends out and the responses it receives. Turning on debug shows you the responses. Turning on d2 shows you the queries as well. When you want to turn off debugging completely, you have to use `set nodebug`, since `set nod2` only turns off level 2 debugging. After the following trace, we'll explain some parts of the packet output. If you want, you can pull out your copy of RFC 1035, turn to page 25, and read along with our explanation.

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > set debug
>     > wormhole
>     Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     ------------
>     Got answer:
>         HEADER:
>             opcode = QUERY, id = 6813, rcode = NOERROR
>             header flags:  response, auth. answer, want recursion,
>             recursion avail.  questions = 1,  answers = 2,
>             authority records = 2,  additional = 3

>         QUESTIONS:
>             wormhole.movie.edu, type = A, class = IN
>         ANSWERS:
>         ->  wormhole.movie.edu
>             internet address = 192.253.253.1
>             ttl = 86400 (1D)
>         ->  wormhole.movie.edu
>             internet address = 192.249.249.1
>             ttl = 86400 (1D)
>         AUTHORITY RECORDS:
>         ->  movie.edu
>             nameserver = terminator.movie.edu
>             ttl = 86400 (1D)
>         ->  movie.edu
>             nameserver = wormhole.movie.edu
>             ttl = 86400 (1D)
>         ADDITIONAL RECORDS:
>         ->  terminator.movie.edu
>             internet address = 192.249.249.3
>             ttl = 86400 (1D)
>         ->  wormhole.movie.edu
>             internet address = 192.253.253.1
>             ttl = 86400 (1D)
>         ->  wormhole.movie.edu
>             internet address = 192.249.249.1
>             ttl = 86400 (1D)

>     ------------
>     Name:    wormhole.movie.edu
>     Addresses:  192.253.253.1, 192.249.249.1

>     > set d2
>     > wormhole
>     Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     This time the query is also shown.

>     ------------
>     SendRequest(), len 36
>         HEADER:
>             opcode = QUERY, id = 6814, rcode = NOERROR
>             header flags:  query, want recursion
>             questions = 1,  answers = 0,  authority records = 0,
>           additional = 0

>         QUESTIONS:
>             wormhole.movie.edu, type = A, class = IN

>     ------------
>     ------------
>     Got answer (164 bytes):

>     The answer is the same as above.

The text between the dashes is the query and response packets. As promised, we will go through the packet contents. DNS packets are composed of five sections:

1. Header section

2. Question section

3. Answer section

4. Authority section

5. Additional section

Header section

  The header section is present in every query and response. The operation code is always QUERY. The only other opcodes are inverse query (IQUERY) and status (STATUS), but those aren't used. The id is used to associate a response with a query and to detect duplicate queries or responses. You have to look in the header flags to see which packets are queries and which are responses. The string `want recursion` means that the querier wants the name server to do all the work. The flag is parroted in the response. The string `auth. answer` means that this response is authoritative. In other words, the response is from the name server's authoritative data, not from its cache data. The response code, `rcode`, can be one of `no error`, `server failure`, `name error` (also known as `nxdomain` or `nonexistent domain`), `not implemented`, or `refused`. The `server failure`, `name error`, `not implemented`, and `refused` response codes cause the `nslookup` "Server failed," "Nonexistent domain," "Not implemented," and "Query refused" errors, respectively. The last four entries in the header section are counters - they indicate how many resource records there are in each of the next four sections.

Question section

  There is always one question in a DNS packet; it includes the name and the requested data type and class. There is never more than one question in a DNS packet. The capability of handling more than one question in a DNS packet would require a redesign of the packet format. For one thing, the single authority bit would have to be changed, because the answer section could contain a mix of authoritative answers and nonauthoritative answers. In the present design, setting the authoritative answer bit means that the name server is an authority for the domain name in the question section.

Answer section

  This section contains the resource records that answer the question. There can be more than one resource record in the response. For example, if the host is multihomed, there will be more than one address resource record.

Authority section

  The authority section is where name server records are returned. When a response refers the querier to some other name servers, those name servers are listed here.

Additional section

  The additional records section adds information that may complete information included in other sections. For instance, if a name server is listed in the authority section, the name server's address is added to the additional records section. After all, to contact the name server, you need to have its address.

For you sticklers for detail, there is a time when the number of questions in a query packet isn't one: in an inverse query, when it's zero. In an inverse query, there is one answer in the query packet, and the question section is empty. The name server fills in the question. But, as we said, inverse queries are almost nonexistent.

### 11.6.2 Querying Like a BIND Name Server

You can make `nslookup` send out the same query packet a name server would. Name server query packets are not much different from resolver packets. The primary difference in the query packets is that resolvers request recursive services, and name servers seldom do. Recursion is the default with `nslookup`, so you have to explicitly turn it off. The difference in operation between a resolver and a name server is that the resolver implements the search list, and the name server doesn't. By default, `nslookup` implements the search list, so that, too, has to be turned off. Of course, judicious use of the trailing dot will have the same effect.

In raw `nslookup` terms, this means that to query like a resolver, you use `nslookup`'s default settings. To query like a name server, use `set norecurse` and `set nosearch`. On the command line, that's `nslookup -norecurse -nosearch`.

When a BIND name server gets a query, it looks for the answer in its cache. If it doesn't have the answer, and it is authoritative for the domain, the name server responds that the name doesn't exist or that there is no data for that type. If the name server doesn't have the answer, and it is not authoritative for the domain, it starts walking up the domain tree looking for NS records. There will always be NS records somewhere higher in the domain tree. As a last resort, it will use the NS records at the root domain, the highest level.

If the name server received a nonrecursive query, it would respond to the querier by giving the NS records that it had found. On the other hand, if the original query was a recursive query, the name server would then query the remote name servers in the NS records that it found. When the name server receives a response from one of the remote name servers, it caches the response, and repeats this process, if necessary. The remote server's response will either have the answer to the question or it will contain a list of name servers lower in the domain tree and closer to the answer.

Let's assume for our example that we are trying to satisfy a recursive query and that we didn't find any NS records until we checked the gov domain. That is, in fact, the case when we ask the name server on relay.hp.com about www.whitehouse.gov - it doesn't find any NS records until the gov domain. From there we switch servers to a gov name server and ask the same question. It directs us to the whitehouse.gov servers. We then switch to a whitehouse.gov name server and ask the same question:

>     % nslookup
>     Default Server:  relay.hp.com
>     Address:  15.255.152.2

>     > set norec            - Query like a name server: turn off recursion
>     > set nosearch         - turn off the search list
>     > www.whitehouse.gov   - We don't need to dot-terminate since we've turned
>                            - search off
>     Server:  relay.hp.com
>     Address:  15.255.152.2

>     Name: www.whitehouse.gov
>     Served by:
>     - H.ROOT-SERVERS.NET
>      128.63.2.53
>      gov
>     - B.ROOT-SERVERS.NET
>      128.9.0.107
>      gov
>     - C.ROOT-SERVERS.NET
>      192.33.4.12
>      gov
>     - D.ROOT-SERVERS.NET
>      128.8.10.90
>      gov
>     - E.ROOT-SERVERS.NET
>      192.203.230.10
>      gov
>     - I.ROOT-SERVERS.NET
>      192.36.148.17
>      gov
>     - F.ROOT-SERVERS.NET
>      192.5.5.241
>      gov
>     - G.ROOT-SERVERS.NET
>      192.112.36.4
>      gov
>     - A.ROOT-SERVERS.NET
>      198.41.0.4
>      gov

Switch to a gov name server. You may have to turn recursion back on temporarily, if the name server doesn't have the address already cached.

>     > server e.root-servers.net
>     Default Server:  e.root-servers.net
>     Address: 192.203.230.10

Ask the same question of the gov name server. It will refer us to name servers closer to our desired answer.

>     > www.whitehouse.gov.
>     Server:  e.root-servers.net
>     Address:  192.203.230.10

>     Name:    www.whitehouse.gov
>     Served by:
>     - SEC1.DNS.PSI.NET
>               38.8.92.2
>               WHITEHOUSE.GOV
>     - SEC2.DNS.PSI.NET
>               38.8.93.2
>               WHITEHOUSE.GOV

Switch to a whitehouse.gov name server - either of them will do.

>     > server sec1.dns.psi.net.
>     Default Server:  sec1.dns.psi.net
>     Address:  38.8.92.2

>     > www.whitehouse.gov.
>     Server:  sec1.dns.psi.net
>     Address:  38.8.92.2

>     Name:    www.whitehouse.gov
>     Addresses:  198.137.240.91, 198.137.240.92

We hope this example gives you a feeling for how name servers look up names. If you need to refresh your understanding of what this looks like graphically, flip back to Figure 2.10.

Before we move on, notice that we asked each of the servers the very same question: "What's the address for www.whitehouse.gov?" What do you think would happen if the gov name server had already cached www.whitehouse.gov's address itself? The gov name server would have answered the question out of its cache instead of referring you to the whitehouse.gov name servers. Why is this significant? Suppose you messed up a particular host's address in your zone. Someone points it out to you, and you clean up the problem. Even though your name server now has the correct data, some remote sites find the old, messed-up data when they look up the name. One of the name servers higher up in the domain tree, such as a root name server, has cached the incorrect data; when it receives a query for that host's address, it returns the incorrect data instead of referring the querier to your name servers. What makes this problem hard to track down is that only one of the "higher up" name servers has cached the incorrect data, so only some of the remote lookups get the wrong answer - the ones that use this server. Fun, huh? Eventually, though, the "higher up" name server will time out the old record. If you're pressed for time, you can contact the administrators of the remote name server and ask them to kill and restart `named` to flush the cache. Of course, if the remote name server is an important, much-used name server, they may tell you where to go with that suggestion.

### 11.6.3 Zone Transfers

`nslookup` can be used to transfer a whole zone using the `ls` command. This feature is useful for troubleshooting, for figuring out how to spell a remote host's name, or just for counting how many hosts are in some remote domain. Since the output can be substantial, `nslookup` allows you to redirect the output to a file. If you want to bail out in the middle of a transfer, you can interrupt it by typing your interrupt character.

Beware: some hosts won't let you pull a copy of their zone, either for security reasons or to limit the load on their name server host. The Internet is a friendly place, but administrators have to defend their turf.

Let's look at the movie.edu zone. As you will see in the output below, all the zone data is listed - the SOA record is listed twice, which is an artifact of how the data is exchanged during the zone transfer. (BIND 4's `nslookup` only shows you address and name server data, not all the data.)

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > ls movie.edu.
>     @                       4D IN SOA       terminator root.terminator (
>                                             1997080605      ; serial
>                                             3H              ; refresh
>                                             1H              ; retry
>                                             4w2d            ; expiry
>                                             1D )            ; minimum

>                             4D IN NS        terminator
>     terminator              4D IN A         192.249.249.3
>                             4D IN MX        10 terminator
>                             4D IN NS        wormhole
>     wormhole                4D IN A         192.249.249.1
>                             4D IN A         192.253.253.1
>                             4D IN MX        10 wormhole
>     robocop                 4D IN A         192.249.249.2
>                             4D IN MX        10 robocop
>     wh249                   4D IN A         192.249.249.1
>     wh253                   4D IN A         192.253.253.1
>     wh                      4D IN CNAME     wormhole
>     shining                 4D IN A         192.253.253.3
>                             4D IN MX        10 shining
>     localhost               4D IN A         127.0.0.1
>     bitg                    4D IN CNAME     terminator
>     carrie                  4D IN A         192.253.253.4
>                             4D IN MX        10 carrie
>     dh                      4D IN CNAME     diehard
>     diehard                 4D IN A         192.249.249.4
>                             4D IN MX        10 diehard
>     misery                  4D IN A         192.253.253.2
>                             4D IN MX        10 misery
>     @                       4D IN SOA       terminator root.terminator (
>                                             1997080605      ; serial
>                                             3H              ; refresh
>                                             1H              ; retry
>                                             4w2d            ; expiry
>                                             1D )            ; minimum
>     Received 48 answers (0 records).
>     > ls movie.edu  > /tmp/movie   - List all data into /tmp/movie
>     [terminator.movie.edu]
>     Received 48 answers (0 records).

11.5 Common Tasks |  | 11.7 Troubleshooting nslookup Problems